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Abstract 


This memo describes a content negotiation mechanism for facsimile, 
voice and other messaging services that use Internet email. 


Services such as facsimile and voice messaging need to cope with new 
message content formats, yet need to ensure that the content of any 
given message is renderable by the receiving agent. The mechanism 
described here aims to meet these needs in a fashion that is fully 
compatible with the current behaviour and expectations of Internet 
email. 
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1. Introduction 


This memo describes a mechanism for email based content negotiation 
which provides an Internet fax facility comparable to that of 
traditional facsimile, which may be used by other messaging services 
that need similar facilities. 


"Extended Facsimile using Internet Mail" [1] specifies the transfer 
of image data using Internet email protocols. "Indicating Supported 
Media Features Using Extensions to DSN and MDN" [2] describes a 
mechanism for providing the sender with the details of a receiver’s 
capabilities. The capability information thus provided, if stored by 
the sender, can be used in subsequent transfers between the same 
sender and receiver. 


Many communications are one-off or infrequent transfers between a 
given sender and receiver, and cannot benefit from this "do better 
next time" approach. 


An alternative facility available in email (though not widely 
implemented) is for the sender to use 'multipart/alternative” [15] to 
send a message in several different formats, and allow the receiver 
to choose. Apart from the obvious drawback of network bandwidth use, 
this approach does not of itself allow the sender to truly tailor its 
message to a given receiver, or to obtain confirmation that any of 
the alternatives sent was usable by the receiver. 


This memo describes a mechanism that allows better-than-baseline data 
formats to be sent in the first communication between a sender and 


receiver. The same mechanism can also achieve a usable message 
transfer when the sender has based the initial transmission on 
incorrect information about the receiver's capabilities. It allows 


the sender of a message to indicate availability of alternative 
formats, and the receiver to indicate that an alternative format 
should be provided to replace the message data originally 
transmitted. 


When the sender does not have the correct information about a 
receiver's capabilities, the mechanism described here may incur an 
additional message round trip. An important goal of this mechanism 
is to allow enough information to be provided to determine whether or 
not the extra round trip is required. 
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1.1 Structure of this document 
The main part of this memo addresses the following areas: 


Section 2 describes some of the background, and sets out some 
specific goals that are addressed in this specification. 


Section 3 describes the proposed content negotiation framework, 
indicating the flow of information between a sender and receiver. 


Section 4 contains a detailed description of the 'Content- 
alternative” header that is used to convey information about 
alternative available formats. This description is intended to stand 
independently of the rest of this specification, with a view to being 
usable in conjunction with other content negotiation protocols. 


Section 5 describes a new mail message header, ’Original-Message-ID’, 
which is used to correlate alternative data sent during negotiation 
with the original message data, and to distinguish the continuation 
of an old message transaction from the start of a new transaction. 


Section 6 describes extensions to the Message Disposition 
Notification (MDN) framework [4] that support negotiation between the 
communicating parties. 


1.2 Document terminology and conventions 
1.2.1 Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [22]. 


Capability exchange 
An exchange of information between communicating parties 
indicating the kinds of information they can generate or consume. 


Capability identification 
Provision of information by the a receiving agent that indicates 
the kinds of message data that it can accept for presentation to a 
user. 


Content negotiation 
An exchange of information (negotiation metadata) which leads to 
selection of the appropriate representation (variant) when 
transferring a data resource. 
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Message transaction 


A sequence of exchanges between a message sender and receiver that 
accomplish the transfer of message data. 


RFC 2703 [17] introduces several other terms related to content 
negotiation. 


1.2.2 Design goals 


In discussing the goals for content negotiation, {1}, {2}, {3} 
notation is used, per REC 2542, "Terminology and Goals for Internet 
Fax" [3]. The meanings associated with these notations are: 


{1} there is general agreement that this is a critical 
characteristic of any definition of content negotiation for 
Internet Fax. 


{2} most believe that this is an important characteristic of 
content negotiation for Internet Fax. 


{3} there is general belief that this is a useful feature of 
content negotiation for Internet Fax, but that other factors 
might override; a definition that does not provide this 
element is acceptable. 


1.2.3 Other document conventions 


NOTE: Comments like this provide additional nonessential information 
about the rationale behind this document. Such information is not 
needed for building a conformant implementation, but may help those 
who wish to understand the design in greater depth. 


2. Background and goals 

2.1 Background 

2.1.1 Fax and email 
One of the goals of the work to define a facsimile service using 
Internet mail has been to deliver benefits of the traditional Group 3 
Fax service in an email environment. Traditional Group 3 Fax leans 
heavily on the idea that an online exchange of information discloses 


a receiver’s capabilities to the sender before any message data is 
transmitted. 
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By contrast, Internet mail has been developed to operate in a 
different fashion, without any expectation that the sender and 
receiver will exchange information prior to message transfer. One 
consequence of this is that all mail messages must contain some kind 
of meaningful message data: messages that are sent simply to elicit 
information from a receiving message handling agent are not generally 
acceptable in the Internet mail environment. 


To guarantee some level of interoperability, Group 3 Fax and Internet 
mail rely on all receivers being able to deal with some baseline 
format (i.e., a basic image format or plain ASCII text, 
respectively). The role of capability exchange or content 
negotiation is to permit better-than baseline capabilities to be 
employed where available. 


One of the challenges addressed by this specification is how to adapt 
the email environment to provide a fax-like service. A sender must 
not make any a priori assumption that the receiver can recognize 
anything other than a simple email message. There are some important 
uses of email that are fundamentally incompatible with the fax model 
of message passing and content negotiation (notably mailing lists). 
So we need to have a way of recognizing when content negotiation is 
possible, without breaking the existing email model. 


2.1.2 Current facilities in Internet Fax 


"Extended Facsimile using Internet Mail" [1] provides for a limited 
provision of receiver capability information to the sender of a 
message, using an extension to Message Disposition Notifications 
[2,4], employing media feature tags [5] and media feature expressions 
[6]. 


This mechanism provides for receiver capabilities to be disclosed 
after a message has been received and processed. This information 
can be used for subsequent transmissions to the same receiver. But 
many communications are one-off messages from a given sender to a 
given receiver, and cannot benefit from this. 


2.2 Closing the loop 


Classic Internet mail is an "open loop" process: no information is 
returned back to the point from which the message is sent. This has 
been unkindly --but accurately-- characterized as "send and pray", 
since it lacks confirmation. 


Sending a message and obtaining confirmation that the message has 


been received is a "closed loop" process: the confirmation sent back 
to the sender creates a loop around which information is passed. 
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Many Internet email agents are not designed to participate in a 
closed loop process, and thus have no responsibility to respond to 
receipt of a message. Later additions to Internet standards, notably 
Delivery Service Notification [18] and Message Disposition 
Notification [4], specify means for certain confirmation responses to 
be sent back to the sender, thereby closing the loop. However 
conformance to these enhancements is optional and full deployment is 
in the future. 


DSN must be fully implemented by the entire infrastructure; further 
when support is lacking, the message is still sent on in open-loop 
fashion. Sometimes, transmission and delivery should instead be 
aborted and the fact be reported to the sender. 


Due to privacy considerations for end-users, MDN usage is entirely 
voluntary. 


Content negotiation is a closed loop function (for the purposes of 
this proposal -- see section 2.3, item (f)), and requires that the 
recipient of a message make some response to the sender. Since 
content negotiation must retro-fit a closed-loop function over 
Internet mail’s voluntary and high-latency environment, a challenge 
for content negotiation in email is to establish that consenting 
parties can recognize a closed loop situation, and hence recognize 
their responsibilities to close the loop. 


Three different loops can be identified in a content negotiation: 


Sender Receiver 
See een as So ee SU eee | 
Ea STRESS <--- Request as data 
Send eh ere ==---- Sophia ds 
a Ree oe en ee SARA E T 


of usable data 


(1) Sender receives acknowledgement that negotiable content has 
been received 


(2) Receiver receives confirmation that its request for data has 
been received. 


(3) Sender receives confirmation that received data is processable, 
or has been processed. 
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Although the content negotiation process is initiated by the sender, 
it is not established until loop (1) is closed with an indication 
that the receiver desires alternative content. 


If content sent with the original message from the sender is 
processable by the receiver, and a confirmation is sent, then the 
entire process is reduced to a simple send/confirm loop: 


Sender Receiver 


Initial message ------ ?==+==8=+59=-= v 


(3). =3====2==5== Coane Confirm receipt 
of usable data 


2.3 Goals for content negotiation 
The primary goal {1} is to provide a mechanism that allows arbitrary 
enhanced content features to be used with Internet fax systems. The 
mechanism should {2} support introduction of new features over time, 


particularly those that are adopted for Group 3 fax. 


Further goals are: 


(a) Must {1} interwork with existing simple mode Internet fax 
systems. 
(b) Must {1} interwork with existing email clients. 


The term "interwork" used above means that the mechanism must 
be introduced in a way that may be ignored by existing systems, 
and systems enhanced to use the negotiation mechanisms will 
behave in a fashion that is expected by existing systems. 
(I.e., existing clients are not expected in any way to 
participate in or be aware of content negotiation.) 


(c) Must {1} avoid transmission of "administrative non messages". 
(I.e., only messages that contain meaningful content for the 
end user may be sent unless it is known that the receiving 
system will interpret them, and not attempt to display them.) 
This requirement has been stated very strongly by the email 
community. 


This means that a sender must not assume that a receiver can 


understand the capability exchange protocol elements, so must 
always start by sending some meaningful message data. 
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(d) Avoid {1} multiple renderings of a message. In situations 
where multiple versions of a message are transferred, the 
receiver must be able to reliably decide on a single version to 
be displayed. 


(e) Minimize {2} round trips needed to complete a transmission. 
Ideally {3} every enhanced transmission will result in simply 
sending data that the recipient can process, and receiving a 
confirmation response. 


(£) The solution adopted should not (3) transmit multiple versions 
of the same data. In particular, it must not {1} rely on 
routinely sending multiple instances of the same data in a 
single message. 


This does not prohibit sending multiple versions of the same 
data, but it must not be a requirement to do so. A sender may 
choose to send multiple versions together (e.g., plain text and 
some other format), but the capability exchange mechanism 
selected must not depend on such behaviour. 


(g) The solution adopted should {2} be consistent with and 
applicable to other Internet email based applications; e.g., 
regular email, voice messaging, unified messaging, etc. 


(h) Allow for a graceful recovery from stale cache information. A 
sender might use historic information to send non-baseline data 
with an initial message. If this turns out to be unusable by 
the recipient, it should still be possible {3} for the baseline 
data, or some other acceptable format, to be selected and 
transferred. 


(i) The mechanism defined should {2} operate cleanly in conjunction 
with the mechanisms already defined for extended mode Internet 
fax (extended DSN and MDN [2], etc.). 


(3) As much as possible, existing email mechanisms should (3) be 
used rather than inventing new ones. (It is clear that some 
new mechanisms will be needed, but they should be defined 
cautiously.) 

(k) The mechanism should {2} be implementable in low memory 
devices. That is, it should not depend on any party being able 


to buffer arbitrary amounts of message data. 
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(It may not be possible to completely satisfy this goal in a 
sending system. But if the sender does not have enough memory 
to buffer some given message, it can choose to not offer 
content negotiation.) 


3. Framework for content negotiation 


This section starts with an outline of the negotiation process, and 
provides greater detail about each stage in following sub-sections. 


1. 


Klyne, 


Sender sends initial message data with an indication of 
alternative formats available (section 3.1). Initial data MAY be 
a baseline or some other guess of what the recipient can handle. 


The receiver has three main options: 


(a) Does not recognize the optional alternative formats, and 
passively accepts the data as sent (section 3.2.1). 


(b) Does recognize the alternatives offered, and actively 
accepts the data as sent (section 3.2.2). 


(c) Recognizes the alternatives offered, and determines that it 
prefers to receive an alternative format. An MDN response 
is sent (i) indicating that the original data was not 
processed, and (ii) containing receiver capability 
information so that the sender may select a suitable 
alternative (section 3.2.3). 


Note that only recipients named in ’to:’, 'cc:” or 'bcc:” 
headers in the original message may request alternative data 
formats in this way. Recipients not named in the original 
message headers MUST NOT attempt to initiate content 
negotiation. 


NOTE: the prohibition on initiation of negotiation by 
recipients other than those explicitly addressed is to avoid 
the sender from having to deal with negotiation requests 
from unexpected parties. 


On receipt of an MDN response indicating preference for an 
alternative data format, the sender MUST select and transmit 
message data matched to the receiver’s declared capabilities, or 
send an indication that the receiver’s request cannot be honoured. 
When sending alternative data, the sender suppresses the 
indication that alternative data is available, so the negotiation 
process cannot loop. 
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4. On receipt of final data from the sender, the receiver sends an 
MDN response indicating acceptance (or otherwise) of the data 
received. 


NOTE: the receiver does not choose the particular data format 
to be received; that choice rests with the sender. We find 
that this approach is simpler than having the receiver choose 
an alternative, because it builds upon existing mechanisms in 
email, and follows the same pattern as a traditional Group 3 
fax. Further, it deals with situations where the range of 
alternatives may be difficult to describe. 


This approach is similar to server driven negotiation in HTTP 
using "Accept" headers [13]. This is distinct to the agent- 
driven style of negotiation provided for HTTP as part of 
Transparent Content Negotiation [14], or which might be 
constructed in email using "multipart/alternative" and 
"message/external-body" MIME types [15]. 


3.1 Send data with an indication of alternatives 


A sender that is prepared to provide alternative message data formats 
MUST send the following message elements: 


(a) a default message data format, 
(b) message identification, in the form of a Message-ID header. 
(c) appropriate 'Content-features” header(s) [7] describing the 


default message data sent, 


(d) a request for Message Disposition Notification [4], 

(e) an indication that it is prepared to send different message 
data, using an /’Alternative-available’ MDN option field [9], 
and 

(£) an indication of the alternative data formats available, in the 
form of 'Content-alternative” header (s) [8]. Note: more than 


one Content-alternative” header MAY be specified; see section 
3.1.3 for more information. 


Having indicated the availability of alternative data formats, the 
sender is expected to hold the necessary information for some time, 
allowing the receiver an opportunity to request such data. But, 
unless it so indicates (see [9]), the sender is not expected to hold 
this information indefinitely; the exact length of time such 
information should be held is not specified here. Thus, the 
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possibility exists that a request for alternative information may 
arrive too late, and the sender will then send an indication that the 
data is no longer available. If message transference is being 
completed within a predetermined time interval (e.g., using [21]), 
then the sender should normally maintain the data for at least that 
period. 


3.1.1 Choice of default data format 


The normal default format is text/plain. This is the format sent 
unless the sender has prior knowledge or expectation of other content 


formats supported by the recipient. Some uses of email presume some 
other default format (e.g. Intenet fax [1] has TIFF profile S [11] as 
its default format; see section 7 of this document). 

"Extended Facsimile Using Internet Mail" [1] and "Indicating 


Supported Media Features Using Extensions to DSN and MDN" [2] 
indicate a possible mechanism for a sender to have prior knowledge of 
receiver capabilities. This specification builds upon the mechanism 
described there. 


As always, the sender may gather information about the receiver in 
other ways beyond the scope of this document (e.g., a directory 
service or the suggested RESCAP protocol). 


3.1.2 MDN request indicating alternate data formats 


When a sender is indicating preparedness to send alternative message 
data, it MUST request a Message Disposition Notification (MDN) [4]. 


It indicates its readiness to send alternative message data by 
including the MDN option 'Alternative-available” [9] with the MDN 
request. Presence of this MDN request option simply indicates that 
the sender is prepared to send some different data format if it has 
more accurate or up-to-date information about the receiver's 
capabilities. Of itself, this option does not indicate whether the 
alternatives are likely to be better or worse than the default data 
sent -- that information is provided by the "Content-alternative" 
header (s) [8]. 


When using the ’Alternative-available’ option in an MDN request, the 


message MUST also contain a ’Message-ID:’ header with a unique 
message identifier. 
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3.1.3 Information about alternative data formats 


A sender can provide information about the alternative message data 
available by applying one or more '*Content-alternative” headers to 
message body parts for which alternative data is available, each 
indicating media features [5,6] of an available alternative. 


The purpose of this information is to allow a receiver to decide 
whether any of the available alternatives are preferable, or likely 
to be preferable, to the default message data provided. 


Not every available alternative is required to be described in this 
way, but the sender should include enough information to allow a 
receiver to determine whether or not it can expect more useful 
message data if it chooses to indicate a preference for some 
alternative that matches its capabilities. 


Alternative formats will often be variations of the content-type 
originally sent. When different content-types can be provided, they 
should be indicated in a corresponding content-alternative header 
using the ‘type’ media feature tag [24]. (See example 8.4.) 


NOTE: the sender is not necessarily expected to describe every 
single alternative format that is available -- indeed, in cases 
where content is generated on-the-fly rather than simply selected 
from an enumeration of possibilities, this may be infeasible. The 
sender is expected to use one or more 'Content-alternative” 
headers to reasonably indicate the range of alternative formats 
available. 


The final format actually sent will always be selected by the 
sender, based on the receiver's capabilities. The 'Content- 
alternative’ headers are provided here simply to allow the 
receiver to make a reasonable decision about whether to request an 
alternative format that better matches its capabilities. 


ALSO NOTE: this header is intended to be usable independently of 
the MDN extension that indicates the sender is prepared to send 
alternative formats. It could be used with a different protocol 
having nothing to do with email or MDN. Thus, the 'Content- 
alternative” header provides information about alternative data 
formats without actually indicating if or how they might be 
obtained. 


Further, the ’Content-alternative’ header applies to a MIME body 


part, where the MDN 'Alternative-available' option applies to the 
message as a whole. 
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The example sections of this memo show how the ’Content-features:’ 
and 'Content-alternative:” MIME headers may be used to describe the 
content provided and available alternatives. 


3.2 Receiver options 


A negotiation-aware system receiving message data without an 
indication of alternative data formats MUST process that message in 
the same way as a standard Internet fax system or email user agent. 


Given an indication of alternative data format options, the receiver 
has three primary options: 


(a) do not recognize the alternatives: passively accept what is 
provided, 
(b) do not prefer the alternatives: actively accept what is 


provided, or 
(c) prefer some alternative format. 
3.2.1 Alternatives not recognized 


This corresponds to the case that the receiver is a simple mode 
Internet fax recipient [12], or a traditional email user agent. 


The receiver does not recognize the alternatives offered, or chooses 
not to recognize them, and simply accepts the data as sent. A 
standard MDN response [4] or an extended MDN response [2] MAY be 
generated at the receiver's option. 


3.2.2 Alternative not desired 


The receiver does recognize the alternatives offered, but 
specifically chooses to accept the data originally offered. An MDN 
response SHOULD be sent indicating acceptance of the data and also 
containing the receiver's capabilities. 


This is the same as the defined behaviour of an Extended Internet Fax 
receiver [1,2]. 


3.2.3 Alternative preferred 
This case extends the behaviour of Extended Internet Fax [1,2] to 
allow an alternative form of data for the current message to be 


transferred. This option may be followed ONLY if the original 
message contains an 'Alternative-available' MDN option (alternative 
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data re-sends may not use this option). Further, this option may be 
followed ONLY if the recipient is explicitly addressed in the message 
headers ("toe ; ces” or CDEC] 


The receiver recognizes that alternative data is available, and based 
on the information provided determines that an alternative format 
would be preferable. An MDN response [4] is sent, which MUST contain 
the following: 


o an ’Alternative-preferred’ disposition modifier [9] indicating 
that some data format other than that originally sent is 
preferred, 


o an ’Original-Message-ID:’ field [4] with the message identifier 
from the received message, and 


o receiver capabilities, per RFC 2530 [2]. 


On sending such an MDN response, the receiver MAY discard the message 
data provided, in the expectation that some alternative will be sent. 
But if the sender has indicated a limited lifetime for the 
alternative data, and the original data received is within the 
receiver’s capability to display, the receiver SHOULD NOT discard it. 
Lacking sufficient memory to hold the original data for a period of 
time within which alternative data would reasonably be received, the 
receiver SHOULD accept and display the original data. In the case 
that the original data is not within the receiver’s capability to 
display then it SHOULD discard the original data and request an 
alternative format. 


NOTE: the above rules are meant to ensure that the content 
negotiation framework does not result in the loss of data that 
would otherwise be received and displayed. 


Having requested alternative data and not displayed the original 
data, the receiver MUST remember this fact and be prepared to take 
corrective action if alternative data is not received within a 
reasonable time (e.g., if the MDN response or transmission of 
alternative data is lost in transit). 


Corrective action might be any of the following: 


(a) re-send the MDN response, and continue waiting for an 
alternative, 
(b) present the data originally supplied (if it is still 


available), or 
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(c) generate an error response indicating loss of data. 


On concluding that alternative data is not forthcoming, the preferred 
option is (b), but this may not be possible for receivers with 
limited memory. 


See Appendix A for further discussion of receiver behaviour options. 


NOTE: A cache control indicator on recipient capabilities has 
been considered, but is not included in this specification. 
(Sometimes, a recipient may want to offer certain capabilities 
only under certain circumstances, and does not wish them to be 
remembered for future use; e.g., not wanting to receive colour 
images for routine communications.) 


NOTE: the receiver does not actually get to select any specific 
data format offered by the sender. The final choice of data 
format is always made by the sender, based on the receiver’s 


declared capabilities. This approach: 
(a) more closely matches the style of T.30 content negotiation, 
(b) provides for clean integration with the current extended 


mode Internet fax specification, 


(c) builds upon existing email mechanisms in a consistent 
fashion, and 


(d) allows for cases (e.g., dynamically generated content) where 
it is not feasible for the sender to enumerate the 
alternatives available. 


3.3 Send alternative message data 


Having offered to provide alternative data by including an 
‘Alternative-available’ option with the original MDN request, and on 
receipt of an MDN response indicating ‘’Alternative-preferred’, the 
sender SHOULD transmit alternative message data that best matches the 
receiver’s declared capabilities. (In the exceptional case that the 
response requesting an alternative data format does not contain 
receiver capabilities, a baseline format should be selected.) 


If any part of the best available message data matching the receiver 
capabilities is the same as that originally sent, it MUST still be 
re-transmitted because the receiver may have discarded the original 
data. Any data sent as a result of receiving an 'Alternative- 
preferred’ response should include an MDN request but SHOULD NOT 
include an 'Alternative-available” disposition notification modifier. 
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If the sender is no longer able to send message data for any reason, 
it MUST send a message to the receiver indicating a failed transfer. 
It SHOULD also generate a report for the receiver indicating the 
failure, containing an MDN request and including an 'Alternative- 
not-available’ disposition notification modifier. 


Any message sent to a receiver in response to a request for 
alternative data MUST include an ’Original-Message-ID:’ header [23] 
containing the Original-message-ID value from the received 
disposition notification message (which is the ’Message-ID:’ from the 
original message). This header serves to correlate the re-send (or 
failure message) with the original message, and also to distinguish a 
re-send from an original message. 


3.4 Confirm receipt of resent message data 


When resent data is received (indicated by presence of an 'original- 
message-ID:’ header field), the receiver processes that data and 
generates an MDN response indicating the final disposition of the 
data received, and also indicating capabilities that may be used for 
future messages, per RFC 2530 [2] and RFC 2532 [1]. 


If the re-send indicates that alternative data is no longer available 
(by including an '*Alternative-not-available” disposition notification 
modifier), and the receiver still holds the original data sent, it 
should display or process the original data and send an MDN response 
indicating the final disposition of that data. Thus, the response to 
an ’Alternative-not-available’ indication may be a successful 
disposition notification. 


If the re-send indicates that alternative data is no longer available 
(by including an ‘’Alternative-not-available’ disposition notification 
modifier), and the receiver has discarded the original data sent, it 


SHOULD: 
(a) display or process the failure message received, OR 
(b) construct and display a message indicating that message data 


has been lost, preferably indicating the sender, time, subject, 
message identifier and other information that may help the 
recipient user to identify the missing message. 


and send a message disposition response indicating a final message 
disposition of "deleted". 
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4, The Content-alternative header 


The ’Content-alternative:’ header is a MIME header that can be 
attached to a MIME body part to indicate availability of some 
alternative form of the data it contains. This header does not, of 
itself, indicate how the alternative form of data may be accessed. 


Using the ABNF notation of RFC 2234 [10], the syntax of a 'Content- 
alternative’ header is defined as: 


Content-alternative-header = 
"Content-alternative" ":" Alternative-feature-expression 


Alternative-feature-expression = 
<As defined for 'Filter” by RFC 2533 [6]> 


More than one 'Content-alternative:” header may be applied to a MIME 
body part, in which case each one is taken to describe a separate 
alternative data format that is available. 


A content-alternative header is used with some MIME-encapsulated 
data, and is interpreted in that context. The intent is to indicate 
possible variations of that data, and it is not necessarily expected 
to be a complete free-standing description of a specific available 
data. Enough information should be provided for a receiver to be 
able to decide whether or not the alternative thus described (a) is 
likely to be an improvement over the actual data provided, and (b) is 
likely to be processable by the receiver. 


Thus, when interpreting a Content-alternative header value, a 
receiver may assume that features not explicitly mentioned are not 
different in the indicated alternative from the supplied data. For 
example, if a Content-alternative header does not mention an 
alternative MIME content-type, the receiver may assume that the 
available alternative uses the same content-type as the supplied 
data. 


See also the example in section 8.4. 
5. The Original-Message-ID message header 


The ’Original-Message-ID’ header is used to correlate any message 
response or re-send with the original message to which it relates 
(see also sections 3.2.3, 3.3). A re-send is distinct from the 
original message, so it MUST have its own unique Message-ID value 
(per RFC 2822, section 3.6.4). 
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The syntax for this header is: 
"Original-Message-ID" ":" msg-id 

where 'msg-id” is defined by RFC 2822 as: 
msg-id = "<" id-left "@" id-right ">" 


The 'msg-id” value given must be identical to that supplied in the 
Message-ID: header of the original message for which the current 
message is a response or re-send. 


6. MDN extension for alternative data 


Here, we define two extensions to the Message Disposition 
Notification (MDN) protocol [4] to allow a sender to indicate 
readiness to send alternative message data formats, and to allow a 
receiver to indicate a preference for some alternative format. 


Indication of what alternatives may be available or preferred are not 
covered here. This functionality is provided by the 'Content- 
alternative’ MIME header [8] and "Indicating Supported Media Features 
Using Extensions to DSN and MDN" [2]. 


6.1 Indicating readiness to send alternative data 


A sender wishing to indicate its readiness to send alternative 
message data formats must request an MDN response using the MDN 
"Disposition-Notification-To:” header [4]. 


The MDN request is accompanied by a '"Disposition-Notification- 
Options:’ header containing the parameter 'Alternative-available' 
with an importance value of 'optional'. (The significance of 
‘optional’ is that receiving agents unaware of this option do not 
generate inappropriate failure responses.) 


This specification defines a value for ‘attribute’ to be used in an 
MDN ’Disposition-Notification-Options:’ header [4]: 


attribute =/ "Alternative-available" 


Thus, a sender includes the following headers to indicate that 
alternative message data is available: 


Disposition-Notification-To: 
<sender-address> 
Disposition-Notification-Options: 
Alternative-available=optional,<lifetime> 
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where <lifetime> is "transient" or "permanent", indicating whether 
the alternative data will be made available for just a short while, 
or for an indefinite period. A value of "permanent" indicates that 
the data is held on long term storage and can be expected to be 
available for at least several days, and probably weeks or months. A 
value of "transient" indicates that the alternative data may be 
discarded at any time, though it would normally be held for the 
expected duration of a message transaction. 


NOTE: the <lifetime> parameter is provided to help low-memory 
receivers (which are unable to store received data) avoid loss of 
information through requesting an alternative data format that may 
become unavailable. 


A message sent with a request for an MDN with an 'Alternative- 
available’ option MUST also contain a 'Message-1D:” header field 
[20]. 


6.2 Indicating a preference for alternative data 


The MDN specification [4] defines a number of message disposition 

options that may be reported by the receiver of a message: 
disposition-type = "displayed" 

/ “dispatched" 

/ “processed" 

/ “deleted" 

/ “denied" 

/ "failed" 


disposition-modifier ( "error" / "warning" ) 
/ ( “superseded" / "expired" / 
"mailbox-terminated" ) 


/ disposition-modifier-extension 


This specification defines an additional value for 'disposition- 
modifier-extension’: 


disposition-modifier-extension =/ 
"Alternative-preferred" 


When a receiver requests that an alternative format be sent, it sends 
a message disposition notification message containing the following 
disposition field: 


Disposition: 


<action-mode>/<sending-mode>, 
deleted/alternative-preferred 
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For example, an automatically generated response might contain: 


Disposition: 
automatic-action/MDN-sent-automatically, 
deleted/alternative-preferred 


An MDN response containing an 'alternative-preferred” disposition 
modifier MUST also contain an 'Original-message-1D:” field [4] with 
the ’Message-ID:’ value from the original message. 


An MDN response containing an 'alternative-preferred” disposition 
modifier SHOULD also contain a 'Media-accept-features:” field [2] 
indicating the capabilities that the sender should use in selecting 
an alternative form of message data. If this field is not supplied, 
the sender should assume some baseline feature capabilities. 
Receiver capabilities supplied with an alternative-preferred 
disposition notification MUST NOT be cached: they may apply to the 
current transaction only. 


6.3 Indicating alternative data is no longer available 


A sender that receives a request for alternative data that is no 
longer available, or is unable to provide alternative data matching 
the receiver’s capabilities, MUST respond with an indication of this 
fact, sending a message containing data describing the failure. 


Such a message MUST specify the MDN ’Disposition-Notification-To:’ 
header [4], accompanied by a 'Disposition-Notification-Options:” 
header containing the parameter ’Alternative-not-available’ with an 
importance value of 'required'. 


This specification defines a value for ‘attribute’ to be used in an 
MDN ’Disposition-Notification-Options:’ header [4]: 


attribute =/ "Alternative-not-available" 


Thus, a sender includes the following headers to indicate that the 
alternative message data previously offered is no longer available: 


Disposition-Notification-To: 
<sender-address> 
Disposition-Notification-Options: 
Alternative-not-available=required, (TRUE) 


A message sent with a request for an MDN with an 'Alternative-not- 
available” option MUST also contain an ’Original-message-ID:’ header 
[23] containing the value from the ’Message-ID:’ header of the 
original message. 
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6.4 Indicating loss of original data 


This specification defines an additional value for 'disposition- 
modifier-extension': 


disposition-modifier-extension =/ 
"original-lost" 


When a receiver loses message data because it lacks memory to store 
the original while waiting for an alternative to be sent, it sends a 
message disposition notification containing the following field: 


Disposition: 
<action-mode>/<sending-mode>, 
deleted/original-lost 


For example, an automatically generated response might contain: 


Disposition: 
automatic-action/MDN-sent-automatically, 
deleted/original-lost 


An MDN response containing an ’original-lost’ disposition modifier 
MUST also contain an ’Original-message-ID:’ field [4] with the 
'Message-ID:’ value from the resent message, or from the original 
message (if no re-send has been received). 


6.5 Automatic sending of MDN responses 


In sending an MDN response that requests alternative data, the 
security concerns stated in RFC 2298 [4] (sections 2.1 and 6.2) 
regarding automatic MDN responses must be respected. In particular, 
a system capable of performing content negotiation MUST have an 
option for its user to disable negotiation responses, either 
generally, on a per-message basis, or both. 


7. Internet Fax Considerations 


Internet fax is an application that uses email to exchange document 
images (see RFC RFC 2305 [12] and RFC 2532 [1]). 


Both sender and receiver parts of this specification involve the use 
of media feature expressions. In the context of Internet fax, any 
such expressions SHOULD employ feature tags defined by "Content 


feature schema for Internet fax" [16]. In a wider email context, any 


valid media features MAY be used. 
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8. 


For Internet fax [12], "image/tiff" is the assumed content-type for 


message data. In particular, all Internet fax devices are presumed 
to be capable of sending and receiving the TIFF profile S 
capabilities (Section 3 of [11]). When communication is between 


Internet fax devices, this capability may be assumed. But when 
dealing with devices that go beyond these capabilities defined for 
Internet fax (e.g. generic email agents with fax capabilities) it 
would be better not to assume fax capabilities, and for the 
negotiating parties to be explicit with respect to all their 
capabilities. 


It would be better if even Internet fax devices do not assume that 
they are communicating with other such devices. When using Internet 
email, there is no reliable way to establish this fact. Therefore, 
for any Internet fax device that may reasonably be expected to 
exchange messages with any other email agent, it is RECOMMENDED that 
Internet fax capabilities (such as image/tiff baseline format 
handling) are not assumed but stated explicitly. 


In particular, the 'Media-Accept-Features:” header in receiver MDN 
responses SHOULD explicitly indicate (type="image/tiff") and baseline 
TIFF capabilities, rather than just assuming that they are 
understood. 


Examples 


8.1 Sending enhanced Internet Fax image 


An Internet fax sender has a profile-F (A4, 400x400dpi, MMR) image to 
send to a receiver. The baseline for Internet fax is 200x200dpi and 
MH image compression. 


Sender’s initial message: 


Date: Wed,20 Sep 1995 00:18:00 (EDT) -0400 

From: Jane Sender <Jane_Sender@example.com> 
Message-Id: <199509200019.12345@example.com> 
Subject: Internet FAX Full Mode Content Negotiation 
To: Tom Recipient <Tom_Recipient@example.org> 
Disposition-Notification-To: Jane_Sender@example.com 
Disposition-Notification-Options: 
Alternative-available=optional, permanent 
MIME-Version: 1.0 

Content-Type: multipart/mixed; 
boundary="RAA14128.773615765/ example.com" 
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--RAA14128.773615765/ example.com 
Content-type: image/tiff 
Content-Transfer-Encoding: base64 
Content-features: 

(& (color=Binary) 
image-file-structure=TIFF-minimal) 
dpi=200) 
dpi-xyratio=1) 
paper-size=A4) 
image-coding=MH) 
MRC-mode=0) 
ua-media=stationery) ) 
Content-alternative: 

(€ olor=Binary) 
image-file-structure=TIFF-limited) 
dpi=400) 
dpi-xyratio=1) 
paper-size=A4) 
image-coding=MMR) 
MRC-mode=0) 
ua-media=stationery) ) 


aaa. a 


(c 
( 
( 
( 
( 
( 
( 
( 


[TIFF-FX Profile-S message goes here] 


--RAA14128.773615765/ example .com-- 


Receiver sends MDN response to initial message: 


Klyne, 


Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400 

From: Tom Recipient <Tom_Recipient@example.org> 

Message-Id: <199509200020.12345@example.org> 

Subject: Re: Internet FAX Full Mode Content Negotiation 

To: Jane Sender <Jane_Sender@example.com> 

MIME-Version: 1.0 

Content-Type: multipart/report; 
report-type=disposition-notification; 
boundary="RAA14128.773615766/example.org" 


—-RAA14128.773615766/example.org 


July 2002 


The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to 


Tom Recipient <Tom_Recipient@example.org> with subject 
FAX Full Mode Content Negotiation" has been received. 
alternative form of the message data is requested. 
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--RAA14128.773615766/example.org 
Content-Type: message/disposition-notification 


Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode 
Original-Recipient: rfc822;Tom-Recipientlexample.org 
Final-Recipient: rfc822;Tom-Recipientlexample.org 
Original-Message-1D: <199509200019.12345@example.com> 
Disposition: automatic-action/MDN-sent-automatically; 
deleted/alternative-preferred 

Media-Accept-Features: 

(€ (type="image/tiff") 
(color=Binary) 
(image-file-structure=TIFF) 
(| (& (dpi=200) (dpi-xyratio=200/100) ) 

& (dpi=200) (dpi-xyratio=1) ) 

& (dpi=400) (dpi-xyratio=1) ) ) 

image-coding=[MH, MR, MMR] ) 

& (image-coding=JBIG) 
(image-coding-constraint=JBIG-T85) 
(IBIG-stripe-size=128) ) ) 

(MRC-mode=0) 

(paper-size=[A4,B4]) 

(ua-media=stationery) ) 


( 

( 
dl 
( 


--RAA14128.773615766/example.org-- 


Sender's message with enhanced content: 


Klyne, 


Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400 

From: Jane Sender <Jane_Sender@example.com> 

Message-Id: <199509200021.12345@example.com> 

Original-Message-Id: <199509200019.12345@example.com> 

Subject: Internet FAX Full Mode Image Transmission 

To: Tom Recipient <Tom_Recipient@example.org> 

Disposition-Notification-To: Jane_Sender@example.com 

MIME-Version: 1.0 

Content-Type: multipart/mixed; 
boundary="RAA14128.773615768/ example.com" 


--RAA14128.773615768/ example.com 
Content-type: image/tiff 
Content-Transfer-Encoding: base64 


[TIFF-FX profile-F message goes here] 


--RAA14128.773615768/ example.com-- 
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Receiver sends MDN confirmation of enhanced message content: 


Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400 

From: Tom Recipient <Tom_Recipient@example.org> 

Message-Id: <199509200022.12345@example.org> 

Subject: Re: Internet FAX Full Mode Image Transmission 

To: Jane Sender <Jane_Sender@example.com> 

MIME-Version: 1.0 

Content-Type: multipart/report; 
report-type=disposition-notification; 
boundary="RAA14128.773615769/example.org" 


--RAA14128.773615769/example.org 


The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom 


Recipient <Tom_Recipient@example.org> with subject " Internet FAX 
Full Mode Image Transmission" has been processed in Internet FAX 
Full Mode. 


—--RAA14128.773615769/example.org 
Content-Type: message/disposition-notification 


Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode 
Original-Recipient: rfc822;Tom-Recipient@example.org 
Final-Recipient: rfc822;Tom-Recipientlexample.org 
Original-Message-1D: <199509200021.12345@example.com> 
Disposition: automatic-action/MDN-sent-automatically; processed 
Media-Accept-Features: 
(€ (type="image/tiff") 

(color=Binary) 

(image-file-structure=TIFF) 

(| (& (dpi=200) (dpi-xyratio=200/100) ) 

& (dpi=200) (dpi-xyratio=1) ) 

& (dpi=400) (dpi-xyratio=1) ) ) 

image-coding=[MH, MR, MMR] ) 

& (image-coding=JBIG) 
(image-coding-constraint=JBIG-T85) 
(IBIG-stripe-size=128) ) ) 

(MRC-mode=0) 

(paper-size=[A4,B4]) 

(ua-media=stationery) ) 


( 

( 
(dl 
( 


--RAA14128.773615769/example.org-- 
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8.2 Internet fax with initial data usable 


This example shows how the second and subsequent transfers between 
the systems in the previous example might be conducted. Using 
knowledge gained from the previous exchange, the sender includes 
profile-F data with its first contact. 


Sender's initial message: 


Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400 

From: Jane Sender <Jane_Sender@example.com> 
Message-Id: <199509200019.12345@example.com> 
Subject: Internet FAX Full Mode Content Negotiation 
To: Tom Recipient <Tom_Recipient@example.org> 
Disposition-Notification-To: Jane_Sender@example.com 
Disposition-Notification-Options: 
Alternative-available=optional, permanent 
MIME-Version: 1.0 

Content-Type: multipart/mixed; 
boundary="RAA14128.773615765/ example.com" 


--RAA14128.773615765/ example.com 
Content-type: image/tiff 
Content-Transfer-Encoding: base64 
Content-features: 

(& (color=Binary) 
image-file-structure=TIFF-limited) 
dpi=400) 
dpi-xyratio=1) 
paper-size=A4) 
image-coding=MMR) 
MRC-mode=0) 
ua-media=stationery) ) 
Content-alternative: 

(& (color=Binary) 
image-file-structure=TIFF-minimal) 
dpi=200) 
dpi-xyratio=1) 
paper-size=A4) 
image-coding=MH) 
MRC-mode=0) 

ua-media=stationery) ) 


Na 


( 
( 
( 
( 
( 
( 
( 
(u 


[TIFF-FX Profile-F message goes here] 


--RAA14128.773615765/ example.com-- 
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Receiver sends MDN confirmation of received message content: 


Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400 

From: Tom Recipient <Tom_Recipient@example.org> 

Message-Id: <199509200022.12345@example.org> 

Subject: Re: Internet FAX Full Mode Image Transmission 

To: Jane Sender <Jane_Sender@example.com> 

MIME-Version: 1.0 

Content-Type: multipart/report; 
report-type=disposition-notification; 
boundary="RAA14128.773615769/example.org" 


--RAA14128.773615769/example.org 


The message sent on 1995 Sep 20 at 00:19:00 (EDT) -0400 to Tom 
Recipient <Tom_Recipient@example.org> with subject "Internet FAX 
Full Mode Image Transmission" has been processed in Internet FAX 
Full Mode. 


—--RAA14128.773615769/example.org 
Content-Type: message/disposition-notification 


Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode 
Original-Recipient: rfc822;Tom-Recipient@example.org 
Final-Recipient: rfc822;Tom-Recipientlexample.org 
Original-Message-1D: <199509200021.12345@example.com> 
Disposition: automatic-action/MDN-sent-automatically; processed 
Media-Accept-Features: 
(€ (type="image/tiff") 

(color=Binary) 

(image-file-structure=TIFF) 

(| (& (dpi=200) (dpi-xyratio=200/100) ) 

& (dpi=200) (dpi-xyratio=1) ) 

& (dpi=400) (dpi-xyratio=1) ) ) 

image-coding=[MH, MR, MMR] ) 

& (image-coding=JBIG) 
(image-coding-constraint=JBIG-T85) 
(IBIG-stripe-size=128) ) ) 

(MRC-mode=0) 

(paper-size=[A4,B4]) 

(ua-media=stationery) ) 


( 

( 
(dl 
( 


--RAA14128.773615769/example.org-- 
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8.3 Negotiate to lower receiver capability 


In this example, the sender has incorrectly assumed that the receiver 
has a higher capability, and must re-send lower capability data in 
response to the receiver's response showing lesser capability. 


An Internet fax sends a profile-F (A4, 400x400dpi, MMR) image. When 
the receiver Cannot handle this, it falls back to baseline profile-S. 
As this is a baseline format, it is not necessary to declare that 
capability with the original message. When a receiver is faced with 
data it cannot process from a negotiating sender, it can do no better 
than to respond with a description of its actual capabilities and let 
the sender determine the outcome. 


Sender's initial message: 


Date: Wed, 20 Sep 1995 00:18:00 (EDT)-0400 

From: Jane Sender <Jane_Sender@example.com> 
Message-Id: <199509200019.12345@example.com> 
Subject: Internet FAX Full Mode Negotiate Down 

To: Tom Recipient <Tom_Recipient@example.org> 
Disposition-Notification-To: Jane_Sender@example.com 
Disposition-Notification-Options: 
Alternative-available=optional, permanent 
MIME-Version: 1.0 

Content-Type: multipart/mixed; 
boundary="RAA14128.773615765/ example.com" 


--RAA14128.773615765/ example.com 
Content-type: image/tiff 
Content-Transfer-Encoding: base64 
Content-features: 

(& (color=Binary) 
image-file-structure=TIFF-limited) 
dpi=400) 
dpi-xyratio=1) 
paper-size=A4) 
image-coding=MMR) 
MRC-mode=0) 
ua-media=stationery) ) 


Aaa aa 


[TIFF-FX Profile-F message goes here] 


--RAA14128.773615765/ example.com-- 
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Receiver sends MDN response to initial message: 


Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400 

From: Tom Recipient <Tom_Recipient@example.org> 

Message-Id: <199509200020.12345@example.org> 

Subject: Re: Internet FAX Full Mode Negotiate Down 

To: Jane Sender <Jane_Sender@example.com> 

MIME-Version: 1.0 

Content-Type: multipart/report; 
report-type=disposition-notification; 
boundary="RAA14128.773615766/example.org" 


-—-RAA14128.773615766/example.org 


The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to 

Tom Recipient <Tom_Recipient@example.org> with subject "Internet 
FAX Full Mode Content Negotiation" has been received. An 
alternative form of the message data is requested. 


—-RAA14128.773615766/example.org 
Content-Type: message/disposition-notification 


Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode 

Original-Recipient: rfc822;Tom-Recipientltexample.org 

Final-Recipient: rfc822;Tom-Recipientlexample.org 

Original-Message-1D: <199509200019.12345@example.com> 

Disposition: automatic-action/MDN-sent-automatically; 
deleted/alternative-preferred 

Media-Accept-Features: 

(€ (type="image/tiff") 

color=Binary) 

image-file-structure=TIFF-minimal) 

dpi=200) 

dpi-xyratio=1) 

paper-size=A4) 

image-coding=MH) 

MRC-mode=0) 

ua-media=stationery) ) 


( 
( 
( 
( 
( 
( 
( 
( 


--RAA14128.773615766/example.org-- 
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Sender's message with baseline content: 


Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400 

From: Jane Sender <Jane_Sender@example.com> 

Message-Id: <199509200021.12345@example.com> 

Original-Message-Id: <199509200019.12345@example.com> 

Subject: Internet FAX Full Mode Image Transmission 

To: Tom Recipient <Tom_Recipient@example.org> 

Disposition-Notification-To: Jane_Sender@example.com 

MIME-Version: 1.0 

Content-Type: multipart/mixed; 
boundary="RAA14128.773615768/ example.com" 


--RAA14128.773615768/ example.com 
Content-type: image/tiff 
Content-Transfer-Encoding: base64 


[TIFF-FX profile-S message goes here] 
--RAA14128.773615768/ example.com-- 
Receiver sends MDN confirmation of impoverished message content: 


Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400 

From: Tom Recipient <Tom_Recipient@example.org> 

Message-Id: <199509200022.12345@example.org> 

Subject: Re: Internet FAX Full Mode Image Transmission 

To: Jane Sender <Jane_Sender@example.com> 

MIME-Version: 1.0 

Content-Type: multipart/report; 
report-type=disposition-notification; 
boundary="RAA14128.773615769/example.org" 


—-RAA14128.773615769/example.org 


The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom 


Recipient <Tom_Recipient@example.org> with subject " Internet FAX 
Full Mode Image Transmission" has been processed in Internet FAX 
Full Mode. 


—-RAA14128.773615769/example.org 
Content-Type: message/disposition-notification 
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Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode 
Original-Recipient: rfc822;Tom-Recipient@example.org 
Final-Recipient: rfc822;Tom-Recipientlexample.org 
Original-Message-1D: <199509200021.12345@example.com> 
Disposition: automatic-action/MDN-sent-automatically; processed 
Media-Accept-Features: 

(& (color=Binary) 

anes file-structure=TIFF-minimal) 


( 

( 

(api xyratio=1) 
(paper-size=A4) 
(image-coding=MH) 
(MRC—-mode=0) 
(ua-media=stationery) ) 


--RAA14128.773615769/example.org-- 
8.4 Sending an alternative content type 


As noted in section 4, the sender can offer the data using a 
different MIME content-type. This example shows a profile-F (A4, 
400x400dpi, MMR) image and a limited-colour PDF document offered as 
alternatives to a baseline image/TIFF. 


Sender's initial message: 


(Note that the MIME content type is not specified for the 
image/tiff alternative, being the same as that provided, but 
is mentioned for the application/pdf alternative.) 


Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400 

From: Jane Sender <Jane_Sender@example.com> 
Message-Id: <199509200019.12345@example.com> 
Subject: Internet FAX Full Mode Content Negotiation 
To: Tom Recipient <Tom_Recipient@example.org> 
Disposition-Notification-To: Jane_Sender@example.com 
Disposition-Notification-Options: 
Alternative-available=optional, permanent 
MIME-Version: 1.0 

Content-Type: multipart/mixed; 
boundary="RAA14128.773615765/ example.com" 


--RAA14128.773615765/ example.com 
Content-type: image/tiff 
Content-Transfer-Encoding: base64 
Content-features: 
(& (color=Binary) 
(image-file-structure=TIFF-minimal) 
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(dpi=200) 
(dpi-xyratio=1) 
(paper-size=A4) 
(image-coding=MH) 
(MRC-mode=0) 
(ua-media=stationery) ) 
Content-alternative: 

(& (color=Binary) 
image-file-structure=TIFF-limited) 
dpi=400) 
dpi-xyratio=1) 
paper-size=A4) 
image-coding=MMR) 
MRC-mode=0) 

(ua-media=stationery) ) 
Content-alternative: 

(& (type="application/pdf") 
color=Limited) 
dpi=400) 
paper-size=A4) 
ua-media=stationery) ) 


( 
( 
( 
( 
( 
( 


( 
( 
( 
( 


[TIFF-FX Profile-S message goes here] 
--RAA14128.773615765/ example.com-- 
Receiver sends MDN response to initial message: 


(Note that this response indicates an ability to handle the 
PDF MIME content-types, but with only binary colour.) 


Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400 

From: Tom Recipient <Tom_Recipient@example.org> 

Message-Id: <199509200020.12345@example.org> 

Subject: Re: Internet FAX Full Mode Content Negotiation 

To: Jane Sender <Jane_Sender@example.com> 

MIME-Version: 1.0 

Content-Type: multipart/report; 
report-type=disposition-notification; 
boundary="RAA14128.773615766/example.org" 


—-RAA14128.773615766/example.org 
The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to 
Tom Recipient <Tom_Recipient@example.org> with subject "Internet 


FAX Full Mode Content Negotiation" has been received. An 
alternative form of the message data is requested. 
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--RAA14128.773615766/example.org 
Content-Type: message/disposition-notification 


Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode 
Original-Recipient: rfc822;Tom-Recipientlexample.org 
Final-Recipient: rfc822;Tom-Recipientlexample.org 
Original-Message-1D: <199509200019.12345@example.com> 
Disposition: automatic-action/MDN-sent-automatically; 
deleted/alternative-preferred 
Media-Accept-Features: 
(| (& (type="image/tiff") 
color=Binary) 
image-file-structure=TIFF-minimal) 
pi=200) 
dpi-xyratio=1) 
image-coding=MH) 
MRC-mode=0) 
paper-size=A4) 
ua-media=stationery) ) 
type="application/pdf") 
color=Binary) 
dpi-xyratio=1) 
dpi=[200, 400] ) 
paper-size=[A4,B4]) 
ua-media=stationery) ) ) 


( 
( 
(d 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 


--RAA14128.773615766/example.org-- 
Resend with alternative content-type: 


Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400 

From: Jane Sender <Jane_Sender@example.com> 

Message-Id: <199509200021.12345@example.com> 

Original-Message-Id: <199509200019.12345@example.com> 

Subject: Internet FAX Full Mode Image Transmission 

To: Tom Recipient <Tom_Recipient@example.org> 

Disposition-Notification-To: Jane_Sender@example.com 

MIME-Version: 1.0 

Content-Type: multipart/mixed; 
boundary="RAA14128.773615768/ example.com" 


--RAA14128.773615768/ example.com 
Content-type: application/pdf 
Content-Transfer-Encoding: base64 


[PDF data goes here] 


--RAA14128.773615768/ example.com-- 
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Receiver sends MDN confirmation of enhanced message content: 
(Also indicating the PDF capability for future messages.) 


Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400 

From: Tom Recipient <Tom_Recipient@example.org> 

Message-Id: <199509200022.12345@example.org> 

Subject: Re: Internet FAX Full Mode Image Transmission 

To: Jane Sender <Jane_Sender@example.com> 

MIME-Version: 1.0 

Content-Type: multipart/report; 
report-type=disposition-notification; 
boundary="RAA14128.773615769/example.org" 


--RAA14128.773615769/example.org 


The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom 


Recipient <Tom_Recipient@example.org> with subject " Internet FAX 
Full Mode Image Transmission" has been processed in Internet FAX 
Full Mode. 


--RAA14128.773615769/example.org 
Content-Type: message/disposition-notification 


Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode 
Original-Recipient: rfc822;Tom-Recipient@example.org 
Final-Recipient: rfc822;Tom-Recipientlexample.org 
Original-Message-1D: <199509200021.12345@example.com> 
Disposition: automatic-action/MDN-sent-automatically; processed 
Media-Accept-Features: 

(| (& (type="image/tif£") 
color=Binary) 
image-file-structure=TIFF-minimal) 
dpi=200) 
dpi-xyratio=1) 
image-coding=MH) 
MRC-mode=0) 
paper-size=A4) 
ua-media=stationery) ) 
type="application/pdf") 
color=Binary) 
dpi-xyratio=1) 
dpi=[200,400]) 
paper-size=[A4,B4]) 
ua-media=stationery) ) ) 


( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 


—-RAA14128.773615769/example.org-- 
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9. IANA Considerations 
9.1 New message headers 
This specification defines new email/MIME message headers: 


Content-alternative 
Original-Message-ID 


As such, there being no registry of email headers, it is an update to 
the specifications of RFC 2822 and RFC 2045. 


9.2 MDN extensions 
This specification defines extensions to the Message Disposition 
Notification (MDN) protocol. The sections below are the registration 
templates for these extensions, as required by RFC 2298 [4], section 
10. 


9.2.1 Notification option ’Alternative-available’ 


(a) Disposition-notification-option name: 
Alternative-available 


(b) Syntax: 
(see this document, section 6.1) 


(c) Character-encoding: 
US-ASCII characters only are used 


(d) Semantics: 
(see this document, section 6.1) 


9.2.2 Notification option ’Alternative-not-available’ 


(a) Disposition-notification-option name: 
Alternative-not-available 


(b) Syntax: 
(see this document, section 6.1) 


(c) Character-encoding: 
US-ASCII characters only are used 


(d) Semantics 
(see this document, section 6.3) 
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9.2.3 Disposition modifier ’Alternative-preferred’ 


(a) Disposition-modifier name: 
Alternative-preferred 


(b) Semantics: 
(see this document, section 6.2) 


9.2.4 Disposition modifier ’Original-lost’ 


10. 


11. 


(a) Disposition-modifier name: 
Original-lost 


(b) Semantics: 
(see this document, section 6.4) 


Internationalization considerations 


This specification deals with protocol exchanges between mail user 
agents, and as such does not deal primarily with human readable te 
But not all user agents may automatically handle the protocol 
elements defined here, and may attempt to display text from the 
protocol elements to the user. 


The main candidate for this treatment is the text accompanying a 
disposition notification response that requests alternative 
information. In normal use, the protocol design ensures that the 
recipient can process this response automatically; exceptionally, 
receiving agent may display it to a user. 


Security Considerations 


Security considerations of this specification can be divided into 
main areas: 


o Privacy concerns with automated MDN response generation: see 
section 6.5 of this document, and the security considerations 
section of RFC 2298 [4]. 


o Risks of negotiation: see the security considerations section 
transaction. If alternative data arrives subsequently, it may 
ignored or possibly also displayed or printed. A successful 
completion MDN may be sent to the sender. 
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Appendix A: Implementation issues 


This section is not a normative part of this specification. Rather, 
it discusses some of the issues that were considered during its 
design in a way that we hope will be useful to implementers. 


A.1 Receiver state 


Probably the biggest implication for implementers of this proposal 
compared with standard mail user agents is the need to maintain some 
kind of state information at the receiver while content is being 
negotiated. 


By "receiver state", we mean that a receiver needs to remember that 
it has received an initial message AND that it has requested an 
alternative form of data. Without this, when a receiver responds 
with a request for an alternative data format there is a possibility 
(if the response does not reach the sender) that the message will be 
silently lost, despite its having been delivered to the receiving 
MTA. 


The matter of maintaining receiver state is particularly germane 
because of the requirement to allow low-memory systems to participate 
in the content negotiation. Unlike traditional T.30 facsimile, where 
the negotiation takes place within the duration of a single 
connection, an extended time may be taken to complete a negotiation 
in email. State information must be maintained for all negotiations 
outstanding at any time, and there is no theoretical upper bound on 
how many there may be. 


Keeping receiver state is probably not a problem for systems with 
high capacity storage devices to hold message data and state 
information. The remainder of this section discusses strategies that 
small-system designers might employ to place an upper bound on memory 
that must be reserved for this information. When a receiver is 
really memory constrained then message loss remains a possibility, 
but the mechanisms described here should ensure that it never happens 
silently. 


So what is this "receiver state"? It must contain, as a minimum: 


o the fact that message data was received, and alternative data has 
been requested, 


o a unique message identifier, and 


o the time at which an alternative format request was sent. 
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This allows the receiver to re-issue a request, or to report an 
error, if requested alternative data does not arrive in a reasonable 
time. 


Receiver state may also include: 


o a copy of the data originally received. This allows the receiver 
to display the original data if an alternative is not received. 


o details of the data format supplied, and alternatives offered. 
This permits improved diagnostics if alternative data is not 
received. 


If a receiver of a message with alternative content available does 
not have enough memory to hold new negotiation state information, it 
may fall back to non-negotiation behaviour, accept the data received 
and send an MDN indicating disposition of that data (see sections 
SL La BALL) 


If a receiving system runs low on memory after entering into a 
negotiation, a number of options may be possible: 


o display or print buffered data, if available, and complete the 
transaction. If alternative data arrives subsequently, it may be 
ignored or possibly also displayed or printed. A successful 
completion MDN may be sent to the sender. 


o discard any buffered data, and continue waiting for alternative 
data. If alternative data does not subsequently arrive, a message 
transfer failure should be declared. 


o abort the transfer and declare a message transfer failure: a 
diagnostic message must be displayed to the local user, anda 
failure notification sent to the sender. 


A.2 Receiver buffering of message data 


If a receiver is capable of buffering received message data while 
waiting for an alternative, this is to be preferred because it 
retains the option to display that data if an alternative is not 
received (see above). 


Partial message data should not be buffered for this purpose: 
displaying part of the original message is not an allowable 
substitute for displaying all of the received data. (There may be 
some value in keeping some of the original message data for 
diagnostic purposes.) 
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If a receiver starts to buffer message data pending negotiation, then 
finds that the entire message is too large to buffer, it may choose 
to fall back to "extended mode" and display the incoming data as it 
is received. 


When a sender indicates availability of alternative data, it also 
indicates whether it is permanently or transiently available. The 
intent of this is that if alternative data is transient, a receiver 
should not discard original data received. If necessary, it should 
simply display the original data without requesting an alternative. 


A.3 Sender state 


When a sender indicates that it can offer an alternative format of 
message content, it accepts some responsibility for trying to ensure 
that alternative is available if requested. Thus, the message 
content (both original and any alternative) should be stored for a 
reasonable period, together with any corresponding Message-ID 
value(s). 


A request for retransmission must be accompanied by an Original- 
Message-ID value that the sender can use to correlate with the 
message data originally sent. 


A.4 Timeout of offer of alternatives 


If the sender is operating with a high capacity message storage 
device (e.g., a disk drive), and normally holds the data for extended 
periods (several days or weeks) then it should indicate that the 
alternative data is permanently available (see 6.1): a recipient 
seeing this may discard the original data, assuming that the sender 
will most likely be able to re-transmit. 


If the sender has limited memory capacity, and is likely to be able 
to hold the data for no more than a few minutes or hours, it should 
indicate that the alternative data is transiently available (see 


6.1). If there is doubt about a sender’s ability to keep the message 
content, it should indicate that availability of any alternative is 
transient. 


A.5 Timeout of receiver capabilities 


It should not be assumed that receiver capabilities declared during 
negotiation are available indefinitely. 
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In particular, any receiver capabilities declared on a final message 
confirmation should be regarded as definitive, even if they differ 
from the capabilities associated with the message just accepted. 
These may be stored for future use. 


Any receiver capabilities declared when requesting an alternative 
format should not be stored for future use, as the receiver might be 
selective about the purposes for which those capabilities may be 
used. 


A.6 Relationship to timely delivery 


Some of the issues of sender state maintenance may be simplified if 
content negotiation is used in conjunction with a facility for timely 
delivery (e.g., [21]). If there is a known time window within which 
a response should be received, the sender may be less conservative 
about keeping information about outstanding offers of alternative 
data for extended periods. A sender that exploits timely delivery in 
this way should indicate that the alternative is transiently 
available. 


A. 7 Ephemeral capabilities 


Ephemeral capabilities may present some special problems. Consider 
the case of selection of a particular content variant that may depend 
on an ephemeral setting. 


Imagine someone sending a basic fax to a color fax machine, 


indicating that a color alternative is available. The color fax 
discards the content and sends an MDN which says 
"deleted/alternative-preferred" to the originator. It then runs out 


of colored ink. The originating fax then sends a new message which 
the colored fax cannot print. 


Or consider an the email client in a phone with sound on/off as a 
related problem. When sound is ON, the phone may be able to accept 
voice messages by email. 


This negotiation framework has not been designed with ephemeral 


capabilities in mind, but, with care, may be adaptable to deal with 
them. 
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A.8 Situations where MDNs must not be auto-generated 


Bearing in mind privacy concerns, implementers should be careful that 
systems do not automatically enter into a negotiation exchange in a 
way that may disclose the recipient's whereabouts without first 
having obtained explicit permission. For example, if receiving a 
message depends in any way on the user's physical presence, automatic 
negotiation should not be performed. 


While it may be OK for an unattended fax machine to perform automated 
negotiation, it is not OK for a PC software package to do so without 
the users explicit permission as the PC may be switched on only when 
the user is present. This suggests that default settings in this 
regard should take account of the type of system. 


Appendix B: Candidates for further enhancements 


This appendix lists some possible features of content negotiation 
that were considered, but not included in the current specification. 
In most cases the reasons for exclusion were (a) that they could 
introduce unanticipated additional complexities, and (b) no 
compelling requirement was recognized. 


o Cache control indicator for recipient capabilities. This would 
instruct the sender, or other message system component, that 
capability information in the current message is for the current 
transaction only, and should NOT be remembered for future 
transactions. E.g., a recipient may not wish colour capability to 
be used for routine communications. (See also section A.5 above.) 


o Use of q-values [6] in media feature expressions for indicating 
preference among alternatives available and/or receiver 


preferences. 

o Partial re-sends. There are proposals being developed for 
"partial MDN" responses that can indicate disposition status ona 
per-message-part basis. This opens the possibility of partial 
re-sends when alternative formats are requested for only some of 
the message body parts. The current specification assumes that 
either none or all of message is re-sent when content negotiation 
is used. 


o Allow negotiation with parties other than originally addressed 
recipients of a message. 


o Negotiation response might indicate different receiver endpoint 
with different capabilities. 
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